When a user sends an email to a recipient using SMTP protocol, the email is sent through message transfer agents (MTAs, which are also known as SMTP servers), which are assigned by message exchange (MX) records (also known as MX servers). The MTAs and MX records are managed by entities known in this context as Internet Service Providers (ISPs). These technologies positioned between the sender (user) and the recipient check the validity of the email, and filter out the message in the event that it is determined to be suspicious or invalid. When this happens, the email is said to have “bounced”. A bounce may be categorised as either a “hard bounce” or a “soft bounce”. A “hard bounce” indicates a permanent error, for example the email address is incorrect or the domain name does not exist. A “soft bounce” indicates a temporary error, for example the recipient's inbox is full or the mail server is temporarily unavailable. A soft bounce can also indicate that the email has been rejected by the ISP because the user has a poor reputation, or because the email does not comply with their requirements.
All users build up a sender reputation over time as they send emails. This sender reputation is held by ISPs. When the ISPs handle emails originating from a particular user, the ISPs use the user's sender reputation to determine whether to forward email messages originating from the user to the intended recipients, or to reject (bounce) the emails. The sender reputation is primarily used by the ISPs in an effort to reduce the quantity of email spam messages which are delivered, where email spam is defined as emails containing advertisements which are sent indiscriminately to large volumes of recipients. In particular, ISPs try to prevent the delivery of emails which are generated automatically by programs such as spambots.
There are several factors which can influence sender reputation, some of the key factors including: (1) the volume of emails that a user sends, and in particular whether the volume is consistent; (2) the proportion of emails sent by the user which are addressed to unknown recipients, resulting in hard bounces; (3) the number of complaints against the user received by the ISP, in particular complaints that the messages sent by the user are spam; (4) spam trap hits, where spam traps are email accounts which are set up specifically to see whether they are sent advertising messages, in which case the messages must be spam by definition; (5) permanence, which is the length of time that a user has been actively sending emails; and (6) infrastructure, which applies to high-volume senders, in which case the ISPs check to see whether the user has the type of infrastructure in place that is required in order to handle large volumes of emails effectively.
In addition to the general sender reputation which is held by ISPs, each user also may have a recipient's sender reputation. Each ISP filters incoming email in order to provide the recipient with a cleaner and smaller inbox, which is optimised to include only email messages which are of genuine interest to the recipient, as far as possible. The ISPs use the recipient's interactions such as reporting spam, and managing a “junk mail” inbox, to tailor this process to the recipient's individual preferences. Therefore, if a user's emails are routinely sorted into a recipient's junk mail inbox, this indicates that the user's recipient sender reputation is poor. The ISPs can take recipient sender reputation into account in addition to the general sender reputation when determining whether to deliver a user's email messages. Additionally, if a user has a poor recipient sender reputation with a large number of recipients, this will affect the user's general sender reputation.
Historically, sender reputation has been linked to Internet Protocol (IP) addresses, which has the disadvantage that if several users are using the same IP address to send email, for example if they are using a common email server or email service provider (ESP), their sender reputations are linked to each other. More recently, there has been a shift towards domain based sender reputations, where the sender reputation is linked to the domain name rather than the IP address, meaning that the reputation is more closely tied to the actual user.
Email deliverability, which is a measure of the proportion of emails which are expected to bounce, is a well-known concept in the art. Deliverability is a key concern for marketing companies as it is important for marketers to minimise the proportion of emails which are not successfully delivered. Marketers often send carefully constructed email campaigns which typically contain over 100,000 emails, and often up to a million emails. Several such campaigns may be sent every month, with the campaigns targeted to selected customers. The emails sent are tailored to the group of people who will be receiving them, in order to maximise the effectiveness of the campaign. Therefore, if the emails sent as part of the campaign are not successfully delivered, that represents a significant wasted effort on the part of the user, with the associated cost implications.
Sender reputation is a significant factor in email deliverability, as a poor reputation leads to poor deliverability. If a user has a poor reputation, an ISP may limit how many emails they will deliver for that user in a given time period, or they may block emails from that user altogether. Therefore, it is important to build and maintain a good sender reputation as far as possible.
In addition to sender reputation, there are other factors which affect email deliverability. The first of these is the quality of the information which is available to the marketers for configuring their campaigns; in particular, whether a reasonable proportion of the list of email addresses that the marketers use is valid. Additionally, each ISP has an individual set of requirements that incoming emails from a user have to meet. These requirements include such things as the user maintaining a consistent IP address, including a clear way for recipients to opt out of receiving future email messages from the user, and the formatting of the email. If a user does not configure their email campaign correctly, their email deliverability rate will be low. A typical campaign involves sending billions of emails internationally every month, which may be handled by over 150 different ISPs. Therefore, configuring the campaign to take into account the varying requirements of each ISP and to avoid hard bounces is a complex and demanding task.
It is known in the state of the art to implement strategies for reducing the proportion of emails which are rejected and improve email deliverability by using a process known as bounce management. The strategies incorporated into bounce management systems include reducing the numbers of hard bounces by identifying and removing incorrect addresses, and improving sender reputation by attempting to address some of the contributing factors. However, given the large number of addresses from which a user makes a selection to direct their email campaigns to, removing incorrect addresses can be a time-consuming and laborious process.
When an email message is bounced by an ISP, the user is sent an SMTP bounce message containing details of the bounce. A typical bounce message which a user may receive from an ISP contains information such as: (1) the date of the bounced email; (2) the delivery status notification (DSN) code, which specifies the category of bounce according to recognised standards RFC821 or RFC1893; (3) an SMTP message containing an explanation of the cause of non-delivery of the email; (4) information regarding the MTA which bounced the email: and (5) the email message header and/or message body. One particular problem in handling bounces is that not all ISPs adhere to the recognised standard, and often an incorrect diagnostic code is applied. This makes it difficult to identify the precise cause of the bounce in order to prevent future bounces, and sometimes results in bounce management systems rejecting valid email addresses, or retaining invalid addresses.
Against this background, in order to provide an improved level of deliverability, it is desirable to provide an architecture for sending high volumes of emails which overcomes or substantially alleviates some of the above described problems in the state of the art.